1. Field of the Invention
The invention relates to graphical methods for debugging electronic circuits. More particularly, the invention relates to an interactive graphical software tool for probing and stimulating circuits in programmable logic devices such as field programmable gate arrays (FPGAs).
2. Description of the Background Art
Electronic systems including programmable logic devices have been increasing in popularity and are now common. However, while many hardware platforms have been built, software support for testing and debugging the programmable devices in these systems has lagged. In the area of software support, the emphasis has been on design tools. By contrast, few debug environments for the programmable devices in these logic systems have been developed. While the programmable devices are typically thoroughly tested prior to being included in the systems, it has heretofore been difficult to completely test configured (programmed) devices within the system. The post-programming configuration data must be inferred from the behavior of the programmed device, or from viewing the states of known "probe points" on the device.
Some debug tools for programmable logic systems are known. These tools typically provide one or both of two types of functionality, symbolic debug and state readback display. Symbolic debug provides a table of variable or signal names whose value changes over time. The data may be displayed as a table or as a waveform, similar to a hardware logic analyzer. The variable or signal names correspond to probe points. One such debug tool, the "Xilinx Hardware Debugger", is described in the "Hardware Debugger Reference/User Guide" (hereinafter referred to as the "Xilinx Hardware Debugger Guide"), published October, 1995, available from Xilinx, Inc., 2100 Logic Drive, San Jose, Calif. 95124, which is incorporated herein by reference in its entirety. (Xilinx, Inc., owner of the copyright, has no objection to copying these and other pages referenced herein but otherwise reserves all copyright rights whatsoever.) As shown on page 1-2 of the Xilinx Hardware Debugger Guide, the probe points are limited to Configurable Logic Block (CLB) outputs, I/O Block (IOB) outputs, and RAM/ROM outputs for the Xilinx XC4000 FGPA device. The symbolic debug process is described in Chapter 6 of the Xilinx Hardware Debugger Guide.
State readback display provides the complete state of the supported latched signals of the FPGA device, typically the outputs of each flip-flop or CLB. Patrice Bertin and Hervi Touati reference a software programming environment called "SHOWRB" that can display the state of each FPGA flip-flop in pages 133-138 of "IEEE Workshop on FPGAs for Custom Computing Machines", edited by Duncan A. Buell and Kenneth L. Pocek, published April, 1994 by the IEEE Computer Society Press, Los Alamitos, Calif., which pages are incorporated herein by reference.
When either symbolic debug or state readback display is used, the functionality of the configured device can be verified by watching the behavior of the displayed probe points in response to inputs applied to device input (or input/output) pads. The Xilinx Hardware Debugger supplies a limited number of input signals to the input/output (I/O) pins of the configured device: clocks, configuration input data (as part of a configuration bitstream), configuration control signals, and a signal that triggers a configuration data readback sequence. (See pages 4-7 and 4-8 of the Xilinx Hardware Debugger Guide.) Other inputs can be externally generated and applied to other I/O pins.
The Xilinx Hardware Debugger also offers a means to verify that the configuration data loaded into the device matches the bitstream used to configure the device. As described on pages 5-5 and 5-6 of the Xilinx Hardware Debugger Guide, when the Verify command is issued, the number of verified bits is reported. The user must then check that the number of verified bits corresponds to the number of downloaded bits. If the numbers correspond, the configuration data matches the bitstream. If not, an error has occurred. The location of the error is not reported. The symbolic debug data, observed data about the behavior of the system, or other data must be used to track down the error. The resulting debug process can be time-consuming and laborious.
It is therefore desirable to have direct access to the configuration data of a configured device in order to more quickly and easily determine the source of an error in a configured device that is part of an electronic system. It is also desirable to simplify the debug process by providing the ability to apply stimulus to probe points distributed throughout the configured device, rather than to a set of I/O pins having limited functionality.